Thanks for your suggestion.

Maybe you have misunderstood the meaning of "Always". This is the definition:

every time the kubelet launches a container, the kubelet queries the container image registry to resolve the name to an image digest. If the kubelet has a container image with that exact digest cached locally, the kubelet uses its cached image; otherwise, the kubelet pulls the image with the resolved digest, and uses that image to launch the container.
https://kubernetes.io/docs/concepts/containers/images/#image-pull-policy

Based on that, I don't think that you are going to save bandwidth if you use "IfNotPresent" instead of "Always".

It's just a quick digest check with the registry, not a download of the image.

I have seen the image being pulled from DockerHub each time a cronjob is performed 🤔
With my patch applied, this no longer happens.

FWIW, this is a deployment based on k3s.

@zonque Have you tried to open an issue in the k3s repository to report that strange behavior (incompatible with k8s documentation)?

Hmm. The reason is probably that k3s does not come with a full registry by default. But tbh, I find the k8s documentation a bit ambiguous, and would rather argue that there is no need to pull an image if it does exist locally, and hence 'IfNotPresent' appears the right choice 🤷

Could this setting be made configurable by the user of Cuber maybe?

I find the k8s documentation a bit ambiguous, and would rather argue that there is no need to pull an image if it does exist locally

K8s documentation is pretty clear: only the image hash is checked, there isn't any download if the image is already present locally. You can also find a confirmation of that by searching online.

hence 'IfNotPresent' appears the right choice

It depends. There are pros and cons.

It depends. There are pros and cons.

I'm curious what the cons would be. IfNotPresent works very well for my setups so far 🙂

@zonque You can find many discussions by searching "imagepullpolicy ifnotpresent vs always".

For example:

• if you set Cuber release you can set an image not generated by Cuber (and in that case the same tag, like "latest", may be reused for different images / builds, for example in a test or staging environment)
• even in production having Always makes sure that the image in the repository is always the same image that is running in Kubernetes (you don't have the risk of using an outdated cache or inconsistencies for unexpected reasons). That can also help for compliance.

Understood. But can we make it configurable maybe so more use cases are covered?